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ABSTRACT 



The scheduling of events aboard U.S. Navy ships is a 
complex and dynamic problem. Currently, this process is 
primarily manual and involves searching through several 
manuals and instructions to find information. Many times 
the schedules produced are inaccurate, which can make 
conducting activities very difficult and result in crew 
frustration. By automating some of the functions of the 
scheduling process, accurate schedules can be quickly 
produced. As a result, valuable time will be saved and the 
planning and coordination of shipboard activities can be 
effectively accomplished in order to achieve and maintain a 
high level of readiness. This thesis is part of the ongoing 
Argos research project which supports the Navy's paperless 
ship concept by eliminating or minimizing manual procedures 
used on ships. 
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I . INTRODUCTION 



The scheduling of events in any organization is a dynamic 
process which can require a manager's constant attention. 
Aboard U.S. Navy ships, the Operations Officer schedules and 
coordinates events such as underway periods, inspections and 
exercises. The command's schedule is developed following the 
guidance of superiors in the chain of command. This process 
is complicated and changes usually occur with very short 
notice at all levels in the chain of command. 

The process at a shipboard level is normally manual. 
That is, most schedules are written on paper or cardboard. 

As changes occur, these schedules are manually corrected. 
This process is extremely slow, tedious and can lead to 
serious errors. Since this process is manual, many 
schedulers delay making the necessary updates or fail to 
make them at all. In the end, the ship's crew suffers 
because they are not kept properly informed of changes, 
which can lead to frustration and low morale. One 
improvement to the scheduling process could be to automate. 
For instance, by eliminating the need to search through 
manuals for current information, a scheduler could be more 
efficient and effective. 
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Argos is an ongoing research project at the Naval 
Postgraduate School. Its goal is to automate many of the 
manual activities on U.S. Navy ships and eventually make 
them less dependent on paper. All of the Argos applications 
feature a friendly graphical user interface which supports 
text and, to some extent, sound. Thus, anyone can quickly 
become proficient with Argos, whether a computer beginner or 
expert . 

The Argos Scheduling Module was developed using the 
HyperCard scripting language which is now available as part 
of Macintosh system software . 1 Some work has been done to 
develop an application on personal computers using Microsoft 
Diskette Operating System (MS-DOS) ; however, most of the 
applications developed have been on Macintosh computers . 2 
The need for an automated scheduling aid is great. Factors 
which can control a ship's schedule are numerous and changes 
occur constantly. The purpose of this thesis is to 
demonstrate the feasibility of a scheduling tool that can be 
used to automate and simplify the manual procedures which 
are in use today. 



'Macintosh and HyperCard are registered trademarks of 
Apple Computer, Inc. 

Microsoft and MS-DOS are registered trademarks of 
Microsoft Corporation. 
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This thesis is organized as follows: Chapter II 

discusses the scheduling process as it currently exists. 
Hardware constraints are presented in Chapter III. Chapter 
IV discusses the design and use of the scheduling prototype. 
Chapter V discusses the benefits of automating the 
scheduling process and conclusions and recommendations for 
follow on thesis work are presented in Chapter VI. 

HyperCard scripts of the major functions of the prototype 
are contained in the appendix. 



II. BACKGROUND 



An accurate schedule of events is critical to any 
organization. For U.S. Navy ships a schedule is the 
foundation upon which all other activities build. For 
example, maintenance personnel must have up to date 
knowledge of underway periods to facilitate the scheduling 
and accomplishing of preventive maintenance on major pieces 
of machinery which will affect main propulsion. Some 
activities require assistance from other commands or units, 
such as a crane which is used to remove a radar or other 
antenna from the ship's mast. Additionally, personnel must 
know when underway periods and inspections are scheduled in 
order to plan personal items, such as extended travel 
requiring leave. 

A ship's Supply Officer determines how much money will 
be needed to support any special activities based upon 
upcoming events such as port visits. A ship's expenses 
depend upon whether the ship will moor to a pier or whether 
it will anchor out in a harbor as determined in the 
schedule. Perhaps one of the most important aspects of 
knowing a ship's schedule involves personnel training. 
Although simulators and trainers are available for many 
different watch stations, most personnel qualifications on a 
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ship require performing specific activities while the ship 
is underway. Several qualifications must be completed 
within time limits. Surface Warfare officer qualifications 
must be obtained within a reasonable period of time aboard 
ship or one could be dismissed from the Navy. If personnel 
can look at a list of events and determine when underway 
times are scheduled, then training times can be allocated to 
ensure all qualifications are achieved. This is especially 
critical when several people are competing for the same 
qualification. Finally, there are teams which must be 
trained. For example, several fire fighting teams must be 
qualified. The teams are comprised of members from every 
department on board a ship and training requires the 
personnel to be off the ship for two to three days. This 
evolution must be scheduled and promulgated well in advance 
so the impact of personnel shortages can be properly 
handled . 

In spite of its importance, the scheduling process as it 
exists on most U.S. Navy ships today is prone to error and 
confusion. Each individual ship develops a schedule 
following a general outline issued from its squadron. Each 
squadron coordinates the activities of ten to fifteen ships. 
The squadron coordinates its scheduling up through the chain 
of command. Generally, about once every three months a ship 
will receive new guidelines from its squadron listing events 
which must be accomplished. Major underway periods are 
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already scheduled in these guidelines but other events can 
be scheduled by the ship. This task is most often performed 
by the Operations Officer, usually a senior lieutenant. 
Commonly, the process is completely manual and consists of 
listing events on a big piece of paper or cardboard. As 
changes occur, new schedules are made or old schedules are 
erased and annotated to reflect current information. Copies 
of these schedules are then made and distributed throughout 
the ship. Copies may be of poor quality either because of 
poor handwriting or faulty copiers. The end result is that 
many people cannot read or understand these schedules which 
leads to frustration and dissatisfaction. 

The manual process described above has many inherent 
disadvantages including the following: 

• the scheduler must search several instructions and 
manuals to determine event periodicity and event 
prerequisites . 



• if old schedules are lost or destroyed, the formulation 
of new schedules is extremely error prone. 



• because the process is manual, the extra instructions 
and old schedules add weight to a ship which negatively 
affects stability and fuel efficiency. 



• the time consuming nature of these tasks is a deterrent 
to making changes in a timely manner. Sometimes it is 
impossible to keep up with changes as they occur. Such 
is often the case when a ship is underway and schedules 
can change every hour. 



• since the process is so confusing usually one person 
performs all the necessary functions. Again, due to 
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routine personnel turnover, a new scheduler must 
familiarize himself with all of the procedures and 
manuals . 

One way to improve the scheduling process is to 
automate activities which are now done by hand. Of 
particular importance is the elimination of searching 
various sources for information about each event. The 
application must be an improvement over current methods and 
must be designed with a ship's space and weight limitations 
in mind. Finally, the development and implementation of 
this application must be cost effective. [Ref. l:pp. 5-6] 
Throughout the development of the Argos Scheduling 
Module, these considerations were used as guidelines. 
Ultimately, with the help of this application, the 
Operations Officer could have an assistant perform some of 
the scheduling functions and conduct periodic checks to 
ensure completeness and accuracy. This would allow more 
than one person to have detailed knowledge about the process 
which would alleviate some of the problems that are caused 
by personnel turnover. 
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III. OPERATIONAL REQUIREMENTS 



The purpose of this thesis is to develop a prototype 
for automation of a ship's scheduling process. The Argos 
Scheduling Module can enhance the performance of a ship. 

The purpose of this chapter is to define the hardware 
features necessary to make this system easy to learn and 
use . 

The computer must be a platform that can support 
graphics and sound and must be small enough to fit aboard a 
ship with limited space [Ref. l:p. 7] . It must also be 
rugged enough to withstand the rocking and vibration common 
to a shipboard environment. The speed at which this 
computer must perform is critical for some of the Argos 
applications. Finally, price is always a factor when 
considering any new system. Because of the advances made in 
the computer industry, a powerful computer system can be 
purchased for a very reasonable price. 

There are several choices of computer hardware that can 
be selected to support the Argos Scheduling Module. Most of 
the applications for the Argos project to date have been 
developed on Macintosh computers utilizing the HyperCard 
programming language. There are, however, existing software 
packages that can be used to develop similar applications on 
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IBM compatible computers which use Microsoft Disk Operating 
System (MS-DOS) . 

All Macintosh computers are able to support sound and 
are capable of being connected to a network if the 
appropriate software is installed. Any Macintosh computer 
that uses System 7 operating system automatically has the 
appropriate networking software installed. For Macintoshes 
without System 7 operating system, the networking software 
must be purchased separately. Usually the ability to 
support sound and to connect to a network are not part of 
the initial purchase of an IBM compatible computer. These 
capabilities require the purchase of additional computer 
cards which raises the final price of a system. These are 
important factors which must be considered. Although the 
sound and network features will make the initial purchase 
price higher, it is cheaper to buy them installed than it is 
to buy them later. [Ref. l:pp. 7-8] 

Since the acceptance and success of an application 
largely depends upon its user interface, an adequate monitor 
for the computer system is an important consideration. 
Monitors come in various shapes and sizes and can either be 
black and white or color. Over the last few years, monitors 
have become quite inexpensive. High resolution color 
monitors can be purchased for approximately $500. A 
complete Macintosh computer system with a color monitor 
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operating at speeds ranging from 16MHZ to 33MHZ can be 
purchased for approximately $3000. [Ref. l:pp. 7-9] 

The HyperCard language is a logical software tool 
because it supports prototyping. Prototyping can be defined 
as a working application that can be created quickly [Ref. 

2] . The purpose of the prototype is to allow users to 
evaluate a computer application or system prior to its final 
implementation. Thus the prototype development should be 
inexpensive and flexible. Because HyperCard fulfills all of 
these requirements it was chosen for this and previous Argos 
projects . 

The development of an application in HyperCard requires 
the use of one or more stacks. A HyperCard stack is a 
homogeneous collection of information. Each stack consists 
of several cards . A card can contain text or graphics and a 
new card can be added as more information is accumulated. A 
text field is used to write text on a card. Finally, 
buttons are used in cards and stacks to allow the user to 
operate. For example, a user can click his mouse on a 
button and go to a different card or to a different stack. 
Another use of a button could be to play sound or musical 
tunes. The possibilities for a button in any application 
are numerous. [Ref. 3:pp. 27-35] 

In the Argos Scheduling Module, there are six stacks. 
When users open a stack for the first time, they will notice 
that the size of every card in the stack is nine inches. 
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This was designed to allow the application to be run on the 
earlier versions of Macintosh computers which have smaller 
screens. On newer computers with larger monitors, the card 
may not fill the entire screen. The card size can be 
adjusted accordingly, depending upon screen size and the 
amount of RAM available to HyperCard [Ref. 3:p. 106]. It is 
best to leave the card size at nine inches so the 
application can be used on any size monitor. When the size 
of a card is adjusted, some of the buttons and graphics may 
appear slightly offset from their original position. In 
these instances each item must be repositioned separately. 

The six stacks of the Argos Scheduling Module and their 
cards, fields, and buttons perform many of the functions 
necessary for the scheduling process. The information 
required for scheduling, such as event periodicities and 
prerequisites, are also stored in these stacks. Some of the 
information is stored in fields which are visible to the 
user. Other information, such as the amount of fuel burned 
per day for a particular ship's class is hidden from the 
user and only brought into view as necessary. Finally, 
there is information in fields that is completely hidden but 
accessed by an application. No matter what type of field is 
used, it is important to realize that these fields are a 
type of database for any application developed in HyperCard. 

HyperCard is used for prototyping because it provides 
the capability to store and manipulate information on a 
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limited basis. It is not intended to be used in the final 



production system. Research into using a relational 
database in the Argos project is ongoing. In a fully 
operational system, a database management software (DBMS) 
would be used. A DBMS permits users to create, maintain and 
extract information from the database. 

A major distinction between HyperCard and database 
management software exists and must be explained. HyperCard 
lets a user move to other stacks to view or retrieve 
information as needed. One benefit of DBMS is its ability 
to generate reports. DBMS can also perform various 
functions on the output or send it to a printer. HyperCard 
is not designed for generating reports but is optimized for 
quickly looking through existing cards in search of desired 
information. The links between cards or stacks that are 
established in HyperCard are not rigid or finite and can be 
changed as new information is added. [Ref. 3:pp. 8-9] 
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IV. SYSTEM PROTOTYPE 



A. DESIGN 

Four stacks representing different ship classes were 
developed. In each of these, there are five cards which are 
used to collect information about each ship within these 
classes. The following is a description of each of these 
cards within the four stacks. 

The first card welcomes the user to the Argos Scheduling 
Module and is the only card of its type in this project 
(Figure 1) . The second card introduces the user to the 
types of ships which can be scheduled (Figure 2) . Each 
silhouette represents a ship's class that is handled by this 
application [Ref. 4:p. 33]. Each ship is actually a 
transparent button which will lead the user to a different 
stack, each designed for one or two classes of ships. 

As in Figure 2 , there are six buttons which appear on 
every card in the four ship stacks. Two of these buttons 
are arrows which are located at the top of each card. The 
arrow which points to the right is used to advance the user 
one card in that direction. The arrow which points to the 
left performs the same action in a backward direction. On 
the bottom right of every card are four buttons, all of 
which utilize sound [Ref. 4:p 33]. These buttons are called 
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Figure 1 

Scheduling Welcome Screen 



14 






flrgossked 




co 

CO Z 
LD O 
OH \- 
0. I— 
Zi 

LU CD 

§o3 

“SI 

5 _> 

CO 
CO 
LU 
C£ 
CL 



t 

LU H 

U 5 

> LU 

> UJ 
O X 
I- H 



LU 
- J 
X 
Ci 
LU 
X 

u 

CO 



CO 

u 

LU 

>- 

o 

X 

K 

CO 

LU 

C 

C 

z 

< 

CO 

LU 

I- 

< 

CD 

O' 





Figure 2 
Ship Silhouettes 
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icons. An icon is a graphic image that can be used on 
screen displays [Ref. 5:p. 565]. Sound was installed in 
these buttons by using a stack called TALK TO ME! written by 
James L. Paul [Ref. 6] . The stack TALK TO ME! uses XCMDS 
which are compiled routines written in a language other than 
HyperCard which can do something that HyperCard cannot : in 

this case create sound [Ref. 7]. The first button, which 
looks like an open palm, is used to quit this application 
and HyperCard. The second button will enable a HELP stack, 
which provides a brief description of the design of this 
project and how to use the buttons. One card of this stack 
is shown in Figure 3. [Ref. 4:p. 134] The next button 
looks like a printer and is used to print out the card being 
viewed. The last button resembles a lighthouse and removes 
the user from this application but does not quit HyperCard. 
The sound alerts the user that these buttons perform special 
functions . 

Moving to the next card the user will see six text 
fields called scrolling fields (Figure 4) . By clicking the 
mouse on one of the arrows along the right edge of these 
fields additional information can be seen. In the first 
text field there is a list of inspections and events. Some 
of these are marked with an asterisk to signify there are 
special circumstances to be considered when scheduling them. 
By clicking the mouse on the EVENT button the user will see 
another field in which inspection prerequisites are 
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Figure 3 

Help Stack Screen 1 
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List of Inspections and Events 
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listed (Figure 5) [ Ref. 8] . The asterisk ensures an 

inspection or event is properly scheduled. The second 
purpose of this card is to activate the computation of when 
each inspection or event can be scheduled. These dates are 
computed using the periodicity listed (Ref. 8]. Of course, 
the date that an inspection or event will actually be 
completed may vary but these computed dates provide 
guidelines for the scheduler. The third important function 
performed by this card is to compute any event not completed 
within the required periodicities. This information is 
vital because a ship must maintain a certain level of 
training and readiness at all times in order to complete 
upcoming operations. The text in the fields labeled EVENT 
and PERIODICITY cannot be erased or modified by certain 
users. These fields have a property called locked text 
[Ref. 3:p. 143]. This feature can only be activated or 
deactivated by someone with the proper authority and user 
level [Ref. 3:p. 25]. This was designed to ensure the 
integrity of the scheduling information. 

The next card contains text fields which hold the 
current and next schedules, listed in chronological order 
(Figure 6) . A third text field holds the events of a 
specific quarter of either the current or next schedules, 
listed in chronological order. These fields were designed 
to provide the scheduler the ability to view a list of 
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List of Inspections and Events ’with Prerequisites 
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main screen] clear 



several events at a glance which facilitates long range 
planning . 

The function of the next card is to compute fuel 
consumption (Figure 7) . The DBSR button displays different 
classes of ships and their respective daily burn rate for 
fuel (Figure 8) (Ref. 9] . The first text field contains a 
list of employment terms and their respective fuel ratios. 
Both the field which holds daily burn rates and the field 
which holds employment terms are locked text. The purpose 
of this card is to provide a scheduler with a computation of 
the amount of fuel required for specific events. For 
example, the total amount required for a certain month or 
quarter can be computed based on upcoming events. The user 
is also provided with the number of barrels which can be 
used on a daily basis while underway. This feature allows 
either underway or inport refuelings to be scheduled in 
advance . 

The final card that will be used for every ship is the 
Personnel Tempo Reporting Card (Figure 9) . This card 
activates the computation of days personnel spend in 
homeport versus the number of days spent away from homeport . 
This is done each quarter and the quarterly point total is 
added to a cumulative point total in order to monitor 
trends. This trend is also displayed on this card. 

Finally, the scheduler can then enter the recovery date in 
the appropriate text field. The recovery date is defined as 
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the date when a unit will meet personnel tempo minimum 
standards. The minimum is defined by deployment length and 
turn around ratio (TAR) . TAR is the ratio between the 
number of months a unit spends between deployments and the 
length of the last deployment. [Ref. 10] 

The SCHEDULES stack is where the final schedule for a 
ship is printed out using a calendar (Figure 10 and Figure 
11) . The calendars are taken from a stack called STACK 
TEMPLATES which comes as a part of HyperCard. All stacks 
for the different types of ships were designed the same. 
Thus, users will see the same buttons throughout, which cuts 
down on the amount of time required to learn this 
application. Although the scheduling stack is different, 
schedulers should quickly learn how to use it effectively. 
The scheduling stack is really the end product; a useful 
schedule is produced. The other stacks act as worksheets. 
The scheduler inputs data in other stacks and that data is 
organized and displayed in the SCHEDULES stack so the user 
can quickly scan a schedule and base decisions on it. Thus 
the overall objective of making scheduling easier and more 
effective has been achieved. 

B. DESCRIPTION 

The easiest way to begin using the Argos Scheduling 
Module is to double click the mouse on the stack named 
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Figure 10 

Schedules Stack Introduction Screen 
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Argossked. This action will enable the user to see the 
first card of this stack (Figure 1) , which slowly dissolves 
to the second. The second card contains rectangular buttons 
which allow the user to perform scheduling actions. Every 
button in this application which is rectangular has a shadow 
visual effect. This is done to distinguish these buttons 
from some of the text fields, which are also rectangular. 

The first button which can be used is the BUILD button. 
When the user clicks the mouse on this button, a box will 
appear that will require input from the user. This box is 
called a dialog box, and is used throughout this project. 

The first dialog box asks the user to input what type of 
ship will be added to the stack (e.g., FFG, CG, etc.). 

Next, the user is asked to input the number of a specific 
type of ship which is currently scheduled. Finally, the 
user will input the name of the ship. Once this is done, 
four cards will be added to the end of the stack. The user 
can then add appropriate information on each card. This 
function was designed so any number of ships can be added to 
each stack. (HyperCard has a 512 megabyte stack size limit, 
however, this is far more than will ever be needed in this 
project [Ref. 3:p. 129].) The VIEW button is positioned 
next to the BUILD button and is used to view the information 
about a ship already scheduled. A dialog box will prompt 
the user to input the type of ship to be viewed. The use of 
the BUILD button and the VIEW button cause text fields to 
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appear. The O.K. button is used to hide these fields. The 
contents of these fields will remain intact and can be 
brought into view again by using the BUILD or VIEW buttons. 

The next card in each of the ship stacks contains 
several rectangular buttons (Figure 4) . By depressing the 
EVENT button, the scheduler will see a text field in which 
inspection prerequisites are listed (Figure 5) . The 
asterisk beside some of the events ensures an event is 
properly scheduled. The NEXT button is used to compute the 
next date each event can be scheduled based on the 
periodicities listed. Finally, the scheduler can view which 
events were not accomplished by depressing the OVERDUE 
button . 

There are five buttons remaining on this card which 
perform important functions. The NEXT SKED button sorts the 
events in the NEXT field in chronological order and then 
lists these events in the NEXT SKED text field on the third 
card in the ship stacks (Figure 6) . The CURRENT SKED button 
performs the same function on the events listed in the 
CURRENT field and then lists those events in the CURRENT 
SKED text field on the third card. The RESKED button allows 
the user to reschedule an event. The scheduler inputs the 
name of the event that must be rescheduled and the 
application will find that event. The user can then put in 
a new date. 
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Moving to the next card (Figure 6) , the user will see 
the current and next schedules listed in chronological 
order. A certain event can be quickly located by depressing 
the FIND EVENT button. The VIEW QUARTER button is used to 
view an entire quarter of either the current or next 
schedule, in chronological order. The SCHEDULES button 
located in the lower left hand part of the screen is 
extremely important. This button will activate the 
SCHEDULES stack where the events for a ship are actually 
scheduled. 

The computation of fuel consumption is activated by the 
next card (Figure 7) . By depressing the DBSR button, the 
user will see a list of ship classes and their respective 
fuel burn rates (Figure 8) . Clicking the mouse on the 
appropriate ship class will cause the appropriate burn rate 
to appear on this card. To start the process of computing a 
ship's fuel requirement the mouse is moved to the 
appropriate employment term and then depressed. A dialog 
box appears that prompts the scheduler to input the number 
of days spent underway for this specific event or task. 

After all terms have been selected, the FUEL REQ'T button 
will compute the total amount of fuel required in barrels 
and also the daily quota for days spent underway. Finally, 
the RESET button located at the bottom of the card must be 
depressed at the beginning of each new session. This 
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ensures that text is entered correctly into text fields each 
time fuel consumption is computed. 

The final card in the ship stacks is the Personnel Tempo 
Reporting Card (Figure 9) . The BEGIN button will present a 
dialog box requesting input for the number of days spent in 
homeport for a particular quarter. Then, the number of days 
in the quarter for which the perstempo is being figured is 
input. The quarterly point total will then be computed and 
listed. A negative number indicates more days were spent 
away from homeport than in homeport. A positive number 
indicates more time spent in homeport vice away from 
homeport and zero indicates an equal number of days spent in 
homeport and away from homeport. The CUMULATIVE P/T button 
calculates cumulative perstempo points and then displays the 
trend from the previous quarter as improving, declining or 
steady. 

The first card of the SCHEDULES stack contains a card 
field which holds a list of the ships currently scheduled 
(Figure 10) . The VIEW button allows the user to view the 
schedule of one of the ships currently scheduled. The QUIT 
button quits this application and HyperCard. Every other 
card in the SCHEDULES stack contains six buttons (Figure 
11) . On each of these, the COPY button is used to create a 
blank calendar which will be placed at the end of the stack. 
The most important button on each of these cards is the 
SCHEDULE button. This button creates the schedule for a 
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particular ship in the form of a calendar. The DATE button 
is used to put the correct month and year on the calendar. 
The DAYS button is used to label the days for a particular 
month. The QUIT button is used to quit this application and 
HyperCard. Finally, the RETURN button will move the user 
back into the ship stacks to the exact card which was 
originally being used. 

In the HELP stack, the RETURN button is the main button 
which is used (Figure 3). Again, this button will return 
the user to the exact card which was originally being worked 
on in one of the ship stacks. This button also utilizes 
sound. The only other functional buttons in this stack are 
the arrow icons, which are used to move either forward or 
backward . 
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V. BENEFITS OF THE DEVELOPED PROTOTYPE 



The Argos Scheduling Module offers many benefits to the 
users. The most important benefit is that the ship's 
scheduling process can be improved by automating the 
process. A small number of examples has been used in this 
prototype; however, a fully developed system could schedule 
nearly all of the ship's required activities. There may 
always be conflicts that cannot be automatically scheduled 
and perhaps they will be solved manually. Also, as stated 
earlier, a schedule is advisory. There are several factors 
involved in ship's scheduling which simply cannot be 
controlled. For example, a ship may suffer a machinery 
casualty just prior to getting underway which can delay 
departure. These situations will always exist, regardless 
of the scheduling method used. However, an automated 
scheduling system is beneficial by allowing fewer errors. 

One benefit discovered while developing this project is 
the amount of time that can be saved by automating some of 
the scheduling process. The elimination of manually 
searching publications and instructions for information has 
been achieved in this project. In a fully developed system 
using a relational database, the elimination of the manual 
searching will save the user much time. Also, as 
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demonstrated in the SCHEDULES stack, past schedules can be 
maintained in an organized manner and reproduced on a 
moment's notice. The manual process wastes time when 
operators or schedulers try to locate and understand old 
schedules . 

Another benefit of the Argos Scheduling Module is the 
standard appearance or format of the final schedules. The 
manual process allows each scheduler to use many different 
methods to list activities. As mentioned earlier, timelines 
drawn on cardboard or paper are some of the more common 
forms. As changes occur, old schedules are erased or 
written over. After several changes, these schedules are 
difficult to read and understand. However, schedules that 
are produced on a computer in a uniform manner will be much 
easier to update, read and understand. Also, if one 
standard method of displaying schedules is approved, the 
amount of time required to train new personnel will greatly 
decrease. This is crucial given the constant turnover of 
personnel . 

One of the most important features that had to be 
considered when designing this project was how the Argos 
Scheduling Module would work with the other projects already 
completed. In order for the entire Argos project to be 
effective, the separate modules must be integrated to offer 
the greatest benefit to ships. One earlier module completed 
in the Argos project was designed around the maintenance of 
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a gas turbine engine. One function of that application was 
to assist a maintenance man in identifying and ordering a 
faulty part. Pages from the appropriate technical manuals 
were available to the user and the application completed 
most of the paperwork needed to order parts. The Argos 
Scheduling Module could be used in this case to determine 
the consequences of a needed part not being locally 
available. If a few computers were networked together, the 
maintenance man could look at the current schedule to 
determine the next underway period. He could then determine 
if upcoming commitments might be in jeopardy. This can be 
accomplished by simply placing a button in the maintenance 
application that will transfer the user to a stack 
containing a current schedule. Supply personnel could also 
have access to the same schedules and, based on the 
availability and location of a needed part, recommend 
further action, such as a casualty report. 

Some of the other projects developed for Argos involve 
training. In this case, a benefit the Argos Scheduling 
Module offers if integrated is the ability to determine a 
ship's upcoming events so training can be scheduled 
accordingly. For instance, one application allows users to 
practice the steps required to control flooding due to 
underwater hull damage. If a ship is scheduled to go to 
Guantanamo Bay, Cuba, for refresher training, this training 
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application can be utilized to help personnel train and 
improve their skills. 

There are benefits offered by integrating the scheduling 
module with the existing application that schedules 
preventive maintenance checks. Almost every piece of 
equipment on board U.S. Navy ships has one or more 
maintenance checks that must be performed within a certain 
periodicity (e.g., daily, weekly, monthly). Several of 
these checks require the equipment to be tagged out of 
service, that is, the equipment cannot be used until the 
maintenance is completed. On certain equipment this can 
affect the entire ship. For example, radar, communications, 
or other electronic equipment can suffer degraded 
performance because one of the air conditioning units is 
tagged out for maintenance. This could certainly be the 
case if a ship were operating in the Caribbean or the Middle 
East. However, if the preventive maintenance application is 
integrated with the scheduling application, a schedule would 
be readily available to all concerned. Thus, this 
maintenance could be scheduled at a time that would least 
affect ongoing operations. Alternatively, a maintenance man 
could check when the next in port period is and perhaps 
delay maintenance until then. Ideally, current schedules 
would be reviewed prior to formulating a maintenance plan in 
order to avoid rescheduling. 
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The Argos Scheduling Module can be integrated with 
existing projects to greatly benefit users in performing 
their daily tasks. As future projects are designed, this 
scheduling application should reveal many more uses. 
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VI. CONCLUSIONS 



The development of this scheduling prototype in the 
HyperCard environment demonstrated the usefulness of a fully 
operational scheduling tool in which schedules can be 
quickly and accurately produced. These schedules are easy 
to read and understand and can be changed as operational 
requirements dictate. The need to search through numerous 
publications and instructions can be greatly decreased or 
perhaps eliminated. 

An automated scheduling system can also help a scheduler 
become better at his job. For instance, in Figure 5 those 
events with prerequisites are marked with an asterisk and 
the necessary information is provided. This feature should 
alert a scheduler to these prerequisites at all times. An 
ability to easily calculate fuel requirements (Figure 7) 
allows a ship's Operations Officer to analyze his schedule 
in order to perform the most tasks given a certain amount of 
fuel . 

Although one microcomputer could run all of the 
applications developed, several computers networked together 
would be more effective. This way, several members of the 
crew could have access to scheduling information. As 
mentioned earlier, schedules are usually posted in well 
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traveled areas of the ship, but it would be useful if 
certain people (e.g., each division officer or senior 
enlisted in each division) could have access to the 
SCHEDULES stack. This can be accomplished by giving the 
stack a certain password which can be changed as often as 
necessary to ensure security (REF. 3:p. 110). In addition, 
the Operations Officer could prepare a schedule which could 
then be reviewed by the Commanding Officer (CO) on his 
computer. The CO could then use several of the functions 
(fuel requirements, event prerequisites) to verify accuracy. 
This could be accomplished without a formal meeting which 
saves everyone time. Also, the CO can perform his review 
without having to search through all of the applicable 
manuals . 

Although the Argos Scheduling Module has proven 
successful in several areas, there are features which can be 
improved. One of these features involves the rescheduling 
of events. If an event is rescheduled, all of the 
prerequisites must also be rescheduled. In the prototype, 
the user must reschedule each prerequisite separately. 
Relationships between events and prerequisites were not 
defined or programmed. One improvement would be to design 
the system so the prerequisites are rescheduled 
automatically. Another useful feature which could be added 
would be an automatic calculation of the fuel requirements 
for a ship given the activities that are scheduled. In the 
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prototype, this is accomplished using a separate card but 
the capability to automatically calculate fuel requirements 
based on a current schedule would be very useful . 

As the Navy continues to respond to downsizing efforts 
and budget reductions as a result of events around the 
world, ships may spend more time in port. One way to 
overcome some of the problems associated with this situation 
is to take advantage of every underway opportunity to 
maximize training. This will require a schedule which is 
accurate and easy to modify in order to exploit any and all 
opportunities. The Argos Scheduling Module can provide 
these capabilities. It is an application that should help 
any ship take advantage of available resources in order to 
maintain a high degree of readiness. 
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APPENDIX 



script of card button id 15 = "view' 7 



on mouseUp 

— this button allows a user to view a ship already scheduled 
global counter 

ASK "WHAT TYPE OF SHIP WOULD YOU LIKE TO VIEW" 
if it is ff then 
show card field ff 
else 

if it is dd then 
show card field dd 
else 

if it is ffg then 
show card field ffg 
else 

if it is ddg then 
show card field ddg 
else if it is empty then exit mouseUp 
end if 
end if 
end if 

ASK "PLEASE ENTER THE NAME OF THE SHIP YOU WOULD LIKE TO VIEW" 

hide card field ff 

hide card field dd 

hide card field ffg 

hide card field ddg 

find whole it in card field "ship name" 
if it is empty then exit mouseUp 
end mouseUp 
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2/11/92 9:30 AM 



Script of card button id 12 = "BUILD 



1 



on mouseUp 

ask "WHICH TYPE OF SHIP WOULD YOU LIKE TO ADD?" 
if it is ff then 
show card field ff 
else 

if it is ffg then 
show card field ffg 
else 

if it is dd then 
show card field dd 
else 

if it is ddg then 
show card field ddg 
else if it is empty then exit mouseUp 
end if 
end if 
end if 

unmark all cards -- just to be sure 

global counter -- variable used for writing to ff ,ffg,dd,ddg fields 
ask "HOW MANY SHIPS ARE CURRENTLY SCHEDULED?" 
if it is empty then exit mouseUp 
put it into counter 

ASK"PLEASE ENTER THE NAME OF THE SHIP YOU WOULD LIKE TO ADD, FOLLOWED- 
BY THE SHIP TYPE (e.g. USS ANTRIM, FFG)" 

— item two is used to indicate which cd field to put it into 
if it is empty then exit mouseUp 
if item 2 of it is "ff" then 

put item 1 of it into line counter +1 of card field ff 
else 

if item 2 of it is "ffg" then 

put item 1 of it into line counter +1 of card field ffg 
else 

if item 2 of it is "dd" then 

put item 1 of it into line counter +1 of card field dd 
else 

if item 2 of it is "ddg" then 

put item 1 of it into line counter + 1 of card field ddg 
end if 
end if 
end if 
end if 

lock screen -- the following script is used to add a ship to the stack 

go to card "EX1" 

doMenu "copy card" 

go to last card of stack 

doMenu "paste card" 

set marked of this card to true -- set to true in order to find later 

go to card "EX2" 

doMenu "copy card" 

go to last card of stack 

doMenu "paste card" 

go to card "EX3" 

doMenu "copy card" 

go to last card of stack 

doMenu "paste card" 

go to card "EX4" 

doMenu "copy card" 

go to last card of stack 44 

doMenu "paste card" 
go to first marked card 
end mouseUp 



Script of card button id 22 = "NEXT 
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710/92 21:59 



on mouseUp 

-- this script computes the next date of each event based on the 
-- periodicities given. The time periods of day, week and month 
-- are converted to seconds for the computations required, 
put the number of lines of card field M date M into x 
repeat with num = 1 to x 

put line num of card field "date" into datehold 
convert datehold to seconds 

put line num of card field "periodicity" into line num of perhold 
if line num of card field "periods'’ = "weeks" 
then 

multiply line num of perhold by 604800 
put line num of perhold into sevendays 
add datehold to sevendays 
convert sevendays to short date 

put sevendays into line num of card field "ndate" 
else 

if line num of card field "periods" = "months" 
then 

multiply line num of perhold by 2592000 
put line num of perhold into thirtydays 
add datehold to thirtydays 
convert thirtydays to short date 

put thirtydays into line num of card field "ndate" 
else 

if line num of card field "periods'^ "days" 
then multiply line num of perhold by 86400 
put line num of perhold into oneday 
add datehold to oneday 
convert oneday to short date 

put oneday into line num of card field "ndate" 
end if 
end i f 
end repeat 
end mouseUp 
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Script of card button id 67 = ’’overdue 



1 



on mousellp 

-- this script calculates the next time for each event based on 
-- the periodicities listed 

put the number of lines of card field "date” into x 
repeat with num = 1 to x 

put line num of card field "date” into line num of getdate 

put line num of card field "ndate" into line num of getnextdate 

put line num of card field "periodicity" into line num of interval 

convert line num of getdate to seconds 

convert line num of getnextdate to seconds 

subtract line num of getdate from line num- 

of getnextdate 

if line num of card field "periods’’= "weeks" then 
multiply line num of interval by 604800 
else 

if line num of card field "periods"="months" then 
multiply line num of interval by 2592000 
else 

if line num of card field "periods" = "days” then 
multiply line num of interval by 86400 
end if 
end if 
end if 

if line num of getnextdate > line num of interval 
then 

put line num of card field "name”- 
into line num of card field "tango" 
else put empty into line num of card field "tango" 
end repeat 
end mousellp 
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Script of card button id 77 = 



next sked 



1 



on mouseUp 

-- this button sorts names and dates and then puts them into the 
NEXT SKED field on the next card, 
set cursor to watch 
put "I'M WORKING!" 
global hoi dnext sked 

hide card field "next result" -- used to hold names and dates for sorting 
put the number of lines of card field "name" into x 
repeat with num = 1 to x 

put line num of card field "ndate" into item 1- 
of line num of card field "next result" 
put line num of card field "name" into item 2-^ 
of line num of card field "next result" 
end repeat 

sort lines of card field "next result" dateTime 

put card field "next result" into holdnextsked -- holds names and dates to go to next 
go to next card 
hide message box 

put holdnextsked into card field "nextsked" 
end mouseUp 
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Script of card button id 78 = "current sked" 



1 



on mousellp 

-- this button sorts names and dates and puts them into the 

-- CURRENT SKED field on the next card 

set cursor to watch 

puf'I'M WORKING!" 

global hoi dcurr ship 

global nship 

hide card field "result" -- used to hold dates and names for sorting 
set cursor to watch 

put the number of lines of card field "name" into x 
repeat with num = 1 to x 

put line num of card field "date" into item 1 - 
of line num of card field "result” 
put line num of card field "name" into item 2 
of line num of card field "result" 
end repeat 

sort lines of card field "result" dateTime 

put card field "result" into holdcurrsked -- holds sorted dates and names to go to r 
put card field "ship name" into nship 
go to next card 
hide message box 

put holdcurrsked into card field "skedres" 
put nship into card field "nameship" 
end mouseUp 
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2/10/92 10:08 PM 



Script of card button id 2 



view quarter” 



1 



on mouseUp 

-- this button enables the user to view any quarter of the schedule of 
-- events for the current or next schedule 
set cursor to watch 

put "I'M WORKING. THIS WILL TAKE A FEW SECONDS!” 

hide card field "answer” 

ask "PLEASE ENTER 1, 2, 3, or 4.” 

if it is empty then exit mouseUp 

put empty into card field "beta" 

put empty into card field "quarter” 

repeat until it = 1 or it =2 or it =3 or it =4 

ASK ” YOU HAVE MADE AN INCORRECT ENTRY. PLEASE ENTER A 1,2,3 OR 4.” 
end repeat 

if it is empty then exit mouseUp 

put the number of lines of card field "skedres” into x 
repeat with num = 1 to x 

put line num of card field "skedres” into line num of card field -» 

"answer” 

convert item 1 of line num of card field "answer” to dateltems 
if it is "1” then 

if item 2 of line num of card field "answer” < 4 
then 

convert item 1 to 7 of line num of card field "answer” to short date 
put line num of card field "answer" into 
line num of card field "beta" 

put "CURRENT FIRST QUARTER" INTO CARD FIELD "QUARTER" 
end if 
else 

if it is ”2" then 

if item 2 of line num of card field "answer” > 4 -. 
and item 2 of line num of card field "answer”-. 

< 6 then 

convert item 1 to 7 of line num of card field "answer" to short date 
put line num of card field "answer” into line num of card -. 
field "beta” 

put "CURRENT SECOND QUARTER” into card field "quarter” 
end if 
el se 

if it is ”3" then 

if item 2 of line num of card field "answer" > 7 
and item 2 of line num of card field "answer" 

< 9 then 

convert item 1 to 7 of line num of card field "answer" to short date 
put line num of card field "answer” into line num of-, 
card field "beta" 

put "CURRENT THIRD QUARTER” into card field "quarter" 
end if 
else 

if it is "4” then 

if item 2 of line num of card field "answer" > 10-. 
and item 2 of line num of card field "answer”-. 

< 13 then 

convert item 1 to 7 of line num of card field "answer" to short date 
put line num of card field "answer” into line num of -» 
card field "beta" 

put "CVURRENT FOURTH QUARTER” into card field "quarter” 
end if 
end if 
end if 
end if 
end if 
end repeat 
end mouseUp 
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Script of card button id 49 = "FUEL REQ'T 



1 



on mouseUp 

-- this button performs the calculations necessary to calculate 
-- the fuel required for a ship to perform certain events, 
global counter 
hide cd field "fuel" 

put the number of lines of card field "names" into x 
repeat with num = 1 to x 

put card field "burn" into temp -- hold values to perform multiplication 
multiply temp by item 2 of line num of card field "names" 
multiply temp by line num of card field "underway" 
put temp into line num of card field "fuel" 
end repeat 

put line 1 of card field "fuel" into calcfuel 
repeat with num = 2 to x -- to get totals 

add line num of card field "fuel" to calcfuel 
end repeat 

put calcfuel into cd field "total" 

put line 1 of cd field "underway" into tempi 

repeat with num = 2 to x -- to get totals 

add line num of cd field "underway" to tempi 
end repeat 

divide calcfuel by tempi 
put calcfuel into cd field "totalu/w" 
end mouseUp 
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Script of card button id 12 = "BEGIN 



1 



on mouseUp 

— this script calculates the personnel tempo total points 
-- based on input from the user. 

ASK "PLEASE ENTER THE NUMBER OF DAYS THIS SHIP WAS IN HOMEPORT THIS QUARTER" 
put it into alpha 
put it into temp 

ASK "PLEASE ENTER THE NUMBER OF DAYS IN THIS QUARTER" 
put it into beta 
subtract beta from alpha 
put alpha into underway 
add temp to underway 
put underway into card field "total" 
put empty into alpha 
put empty into beta 
end mouseUp 



2/10/92 10:12 PM 



Script of card button id 15 = ’’CUMULATIVE P/T" 



1 



on mouseUp 

-- this computes the personnel tempo points and then computes the 

-- trend from the previous month. 

put card field "ctotal” into temp 

add card field ’’total” to card field "ctotal” 

if card field "ctotal" > temp then 

put "improving" into card field "trend" 
else 

if card field "ctotal" = temp then 
put "steady" into card field "trend" 
else 

if card field "ctotal" < temp then 

put "declining" into card field "trend” 
end i f 
end i f 
end if 
end mouseUp 
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Script of card button id 73 = ’’Schedule 



1 



on mouseUp 

global typeofship 
global destination 

repeat with x = 1 to the number of cards 
set the dontSearch of card x to true 
end repeat 

set the dontSearch of this card to false -- so only one is found 

global itemhold 

global counter 

global count 

global fname 

global box 

global holdit 

global temp 

ask ’’PLEASE ENTER THE NAME OF THE SHIP YOU DESIRE TO SCHEDULE” 
if it is empty then exit mouseup 
put it into holdit 

ask ’’PLEASE ENTER THE SHIP TYPE (e.g. f fg , eg , ddg , etc . ) ” 

if it is empty then exit mouseup 

put it into cd field ’’ship type” 

put cd field ’’ship type” into typeofship 

if typeofship is "ffg” or typeofship is ”ddg" or typeofship is "ft"-* 
or typeofship is ”dd” then 

put ’’Argossked” into destination 
else 

if typeofship is ”cg” or typeofship is ”cv” then 
put ’’cruiser/carrier” into destination 
else 

if typeofship is ”lsd” or typeofship is "1st” - 

or typeofship is ”lha” or typeofship is ”lph”or typeofship is ”bb” then 
put "amphibs” into destination 
else 

if typeofship is ”ao” or typeofship is ”ae” or typeofship is "aor”^ 
or typeofship is "aoe” then 

put "replenishment ships” into destination 
end if 
end if 
end if 
end i f 

schedule -- this script is in the background 
end mouseup 
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Script of background id 2720 = "’ 



on schedule 

-- this script prompts the user for information and then based on 

-- the ship type given , goes to the correct stack and retrieves 

-- the scheduling information.This information is then entered into 

-- the correct text field on each calendar. 

global holdit 

global typeofship 

global destination 

global findname 

answer "HAS THIS SHIP ALREADY BEEN SCHEDULED” with "YES” or "NO" 
if it is "no" then 
lock screen 
push card 
go to card hide 

put the number of lines in card field "list" into count 
put holdit into line count + 1 of card field "list" 
pop card 
end if 

put holdit into cd field "sname" 
set cursor to watch 

put item 1 of cd field "sname" into findname 
put "I'M WORKING" 
lock screen 

go to stack destination -- destination holds the proper ship type 
find whole findname in cd field "ship name" 
go next card 

put cd field "skedres" into comp 

go to stack "sked” 

find whole findname 

put comp into cd field "holder" 

hide msg box 

ask "PLEASE ENTER THE NUMBER OF THIS MONTH” 
put it into box 

if it is empty then exit schedule 

put "I’M WORKING ! THIS WILL TAKE A FEW MINUTES" 

set cursor to watch 

lock screen -- the following repeat loop schedules events 
put the number of lines of cd field "holder" into counter 
repeat with num = 1 to counter 

convert item 1 of line num of cd field "holder” to dateltems 
if item 2 of line num of cd field "holder" = box then 
put item 3 of line num of cd field "holder" into temp 
find whole temp 

put word 3 of the foundField into fname 
put "," into comma 

put comma && item 8 of line num of cd field "holder”^ 
after last item in cd field fname 
else 

push card 

get line num of cd field "holder” 
go to card hide 

put it into line num of cd field "garbage" 
pop card 
end if 
end repeat 

hide the msg box -- the following repeat loop converts the dateltems 
-- to short dates in card field "holder" 

repeat with x= 1 to the number of lines in cd field "holder” 

convert item 1 to 7 of line x of cd field "holder" to short date 
end repeat 54 

end schedule 
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Script of card button id 74 = ’’DATE 



1 



on mouseUp 

-- the following script assigns the proper date to each calendar 
-- based on input from the user 
global day 
global tempyear 

ASK ’’PLEASE ENTER THE MONTH AND THE YEAR IN THE FOLLOWING MANNER: 1,91” 

put cd field ”yearl” && item 2 of it into item 1 of tempyear 

put item 1 of it into item 2 of tempyear 

put item 1 of it into day 

put item 2 of it into cd field ”year2” 

if item 1 of it is ”1” then 

put ’’JANUARY” into cd field "month” 
else 

if item 1 of it is 2 then 

put ’’FEBRUARY” into cd field "month” 
else 

if item 1 of it is 3 then 

put "MARCH” into cd field "month” 
else 

if item 1 of it is 4 then 

put "APRIL” into cd field "month” 
else 

if item 1 of it is 5 then 

put "MAY" into cd field "month" 
else 

if item 1 of it is 6 then 

put "JUNE" into cd field "month” 
else 

if item 1 of it is 7 then 

put "JULY” into cd field "month" 
else 

if item 1 of it is 8 then 

put "AUGUST" into cd field "month" 
else 

if item 1 of it is 9 then 

put "SEPTEMBER" into cd field "month” 
else 

if item 1 of it is 10 then 

put "OCTOBER" into cd field "month" 
else 

if item 1 of it is 11 then 

put "NOVEMBER” into cd field "month" 
else 

if item 1 of it is 12 then 

put ’’DECEMBER" into cd field "month” 
end if 
end if 
end if 
end if 
end if 
end i f 
end if 
end i f 
end if 
end if 
end i f 
end if 
end mouseUp 
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Script of card button id 75 = "DAYS” 



1 



on mouseUp 

-- this button numbers the days of each calendar based on input from 
— the user 
global daycount 
global day 

ask "ON WHAT DAY OF THE WEEK DOES THIS MONTH START?" 
if it is "MONDAY" then 
put 1 into cd field "Ml" 
put number of cd field "Ml" into whatday 
else 

if it is "TUESDAY" then 
put 1 into cd field "Tl" 
put number of cd field "Tl" into whatday 
else 

if it is "WEDNESDAY” then 
put 1 into cd field "Wl" 

put number of cd field "Wl" into whatday 
else if it is "THURSDAY" then 
put 1 into cd field "TH1" 
put number of cd field "TH1" into whatday 
else 

if it is "FRIDAY" then 
put 1 into cd field "FI" 

put number of cd field "FI" into whatday 
else 

if it is "SATURDAY" then 
put 1 into cd field "SI" 

put number of cd field "SI" into whatday 
else 

if it is "SUNDAY" then 

put 1 into cd field "SU1" 

put number of cd field "SU1" into whatday 
end if 
end i f 
end if 
end if 
end if 
end i f 

repeat with x = 1 to 36 
put empty into cd field x 
end repeat 

if day is 1 or day is 3 or day is 5 or day is 7 or day is-. 

8 or day is 10 or day is 12 
then put 31 into daycount 
else 

put 30 into daycount 
if month is 2 then 
if year mod 4=0 
then put 29 into daycount 
else put 28 into daycount 
end if 
end if 

repeat with num = 1 to daycount 

put num into line 1 of cd field whatday 
add 1 to whatday 
end repeat 



end mouseUp 
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